1. Field of the Invention
This invention relates generally to wireless devices as they relate to geographic information systems. More particularly, it relates to the provision of 911 services for wireless users to a Public Safety Answering Point (PSAP).
2. Background of the Related Art
Current public safety infrastructure is heavily wedded to wireline interfaces and to the notion that every E911 caller has a street address-not simply to the notion that latitude/longitude coordinates is more amenable to the mobile phone culture of today. As a result, the E911 industry is challenged with the ability to automatically and reliably deliver location information to the Public Safety Answering Points (PSAPs) for wireless devices. This is also true for most Voice Over Internet Protocol (VoIP) devices, which by the ubiquitous nature of the Internet are not always fixed in location.
For illustration purposes, FIG. 3 shows a conventional E911 VoIP scenario.
In particular, as shown in FIG. 3, a VoIP carrier 100 includes a call server 202 and an Emergency Services Gateway (ESGW) 204.
A service bureau 120 includes a network location information server (LIS) 206, a Session Initiated Protocol (SIP) server (redirect) 208, and a VoIP positioning center (VPC) 210. Also included in the service bureau 120 is an Emergency Services Zone (ESZ) route database (DB) 220, and a validation database (DB) 230.
Also within the network are the Public Switched Telephone Network (PSTN) 130, a selective router 140, a Public Safety Answering Point (PSAP) 180, an Automatic Location Identification (ALI) database 190, a Master Street Address Guide (MSAG) 195, an Internet Protocol (IP) phone 150, a provisioning system 160, and a local Location Information Server (LIS) 170.
FIG. 4 shows exemplary call flow for the conventional E911 VoIP scenario shown in FIG. 3.
In particular, as shown in step 1 of FIG. 4, a caller on the IP phone 150 dials 9-1-1; and the call proceeds to the VoIP call server 202.
In step 2, the VoIP call server 202 sends a Session Initiated Protocol: uniform Resource Identifier (SIP:URI) to the SIP Server (redirect) 208.
In step 3, the SIP Server 208 queries the VoIP Positioning Center (VPC) 210 for an Emergency Services Routing Number (ESRN) and an Emergency Services Query Key (ESQK). This is conventionally based on a fixed street address that is configured for the particular VoIP user.
In step 4, the VoIP Positioning Center (VPC) 210, via the SIP Server 208, returns the ESRN & ESQK to the VoIP Carrier 100.
In step 5, the call server 202 uses the returned ESRN to route the wireless 911 call to the Emergency Services Gateway (ESGW) 204.
In step 6, the Emergency Services Gateway (ESGW) 204 routes the wireless 911 call to the selective router 140.
In step 7, the wireless 911 call is sent to the Public Safety Answering Point (PSAP) with the ESQK.
In step 8, the Public Safety Answering Point (PSAP) queries the Automatic Location Identification (ALI) database 190 using the ESQK.
In step 9, the Automatic Location Identification (ALI) database 190 queries the VoIP Positioning Center (VPC) 210 with the ESQK.
In step 10, the Service Bureau 120 matches the ESQK and returns location information.
Emergency services are most easily provided to a caller using a phone in a fixed location (e.g. a landline). For this situation, a table is created that associates an emergency service number (ESN) to each phone number. However, for a wireless phone the inventors herein realize that this approach no longer works as the location of the phone can change. Given the global positioning satellite (GPS) location (latitude/longitude) of a mobile phone (provided by the relevant cellular service carrier), the task remains to determine the emergency service number (ESN) of the closest PSAP.
Unfortunately, static tables associating phone numbers to ESNs do not work for a wireless or mobile caller, because their location is not determined merely using their phone number and a lookup in the static table. The provision of an acceptable location for a mobile device or even a VoIP device which may or may not be mobile presents a number of challenges, not the least of which is Metro Street Address Guide (MSAG) validation of their location.
Fundamentally, MSAG is a legacy requirement from PSAPs that did (and some still do) have “dumb” terminals that receive the call and display validated street address information to the call taker. In early PSAP systems, information delivery was slow and cumbersome, so the industry worked on developing a set of abbreviations that would allow an address to fit into about 20 characters.
The entire conventional call scenario depicted in FIG. 4 presumes that a database record exists that identifies the location of the customer, and that the database record exists as an MSAG-validated address. In reality, this is not necessarily the case. Nevertheless, current PSAP architectures have entire response procedures built around street addresses only, and use the street address as a key to a table for looking up the appropriate emergency response. Accordingly, the bottom line is that conventional PSAPs require that location information be an MSAG-validated street address to guarantee that the PSAP database lookup will not fail.
Wireless Phase I requirements defined by NENA provide E9-1-1 for VoIP using PSAP administrative lines. Wireless Phase II requirements defined by NENA provide E9-1-1 for VoIP across traditional 9-1-1 channels. In wireless Phase II, the location of the caller is dynamically extracted from the network. This results in a latitude/longitude (lat/lon) coordinate being provided to the PSAP. Those PSAPs which have been upgraded to handle lat/lon receive the information and display it on a screen driven by a Graphical Information System (GIS), i.e., they see a map with a “caller is here” flag or dot. Such a conventional system is suitable in PSAPs which have upgraded to handle these Wireless Phase II calls (currently somewhere north of 40% of all PSAPs). However, older PSAPs still need address information, and they expect to receive an MSAG-validated address. So, for wireless, the address is given as the center of the cell site/sector which is serving the caller. Not very precise, but good enough to get emergency services in a vicinity of a wireless caller.
With Voice Over Internet Protocol (VoIP) usage, it is desirable to apply a similar model as is done in wireless, i.e., to dynamically extract location information from the network, and present it to the PSAP. Unfortunately, VoIP systems, being based on the ubiquitous Internet, can be even more difficult to locate than a wireless device as they do not always have the luxury of a cell site/sector overlay to fall back on. In other words, a VoIP caller can make a 911 call from anywhere in the country, but there is no credible database of MSAG-validated addresses for the Internet routers to deliver the 911 call.
There is a need for a way for wireless and/or VoIP users to have the best of both worlds-provision of location information in latitude/longitude (lat/lon) coordinates to a PSAP, while at the same time providing the PSAP with an MSAG-validated street address location.